Domain Name Service (DNS) is the internet's current mechanism to map a service request (specified as a fully qualified domain name) onto a server that can provide the requested service. However, DNS in its native form cannot identify a “good” or “best” server. Another limitation of DNS is that security is limited to server authentication; client authorisation is not supported.
A commercial problem faced by Internet Service Providers (ISP's) is how to offer differentiated service offerings whilst competing with specialized Content Delivery Service Providers (CDSP's).
Traditional Content Delivery Service Providers (CDSP's) deploy a centralised approach to global traffic management, based on enhancements to DNS. In this approach DNS requests are handled by a central server that uses the IP address within each request to deduce the geographical/topological location of the client/proxy. However, CDSP's do not have the capability to augment this with edge-based server selection as they do not own/operate an edge network. Consequently, their resolution of DNS requests is typically restricted to identifying candidate servers within an edge domain—rather than selecting the “best” server within that domain.
Other DNS based application independent approaches to traffic management such as “Ping” race and DNS response race also suffer from the same shortcomings. The “ping” race approach is where a DNS request triggers synchronized “pings” from a set of candidate servers to a point close to the client, and whereby the server that responds fastest back to the DNS server is preferred. The DNS response race is where a DNS request is passed to each site with candidate servers whereby each site responds to the DNS query with a server IP address such that the fastest response to be received by the client wins. A further shortcoming associated with existing DNS based approaches is that knowledge of client location is often insufficient, especially if the client uses a proxy DNS server that is not very close to the data path. In addition, “ping” based approaches are inadequate as they do not take the server or application load into consideration.
Another application independent approach that can be used to manage internet traffic is Dynamic Routing which is router based. Here, a set of application servers is given a single IP address, and a router performs health checks and advertises a host route for each healthy cluster, whereby the least cost route wins. However, this router approach is not scalable as it fragments forwarding entries in multiple routers because “virtual” IP addresses cannot be equated to specific subnets.
A third type of approach is application dependent and is the HTTP race approach. Here, the HTTP request is communicated by the origin server to a set of candidate servers. Each server then responds simultaneously back to the client, whereby the first response is accepted and that server is chosen. Subsequent responses are rejected as TCP-layer duplicates. As well as having many of the above-mentioned shortcomings, application dependent approaches must be implemented separately for each application of interest.
Furthermore, none of the existing approaches can support session-based Quality of Service (QoS) end-to-end. Using “snapshot” and or averaged network delay statistics does not guarantee that adequate network resources will be available for the duration of the transaction of interest.
There is therefore a need for a network traffic management system that enables an ISP to offer an edge-based server selection capability directly to Content Providers.
There is also a need for a network traffic management system that enables an ISP to find the best server from which to deliver a piece of content under given conditions involving network, server and/or application load, and optionally ensuring that the path from client to server is guaranteed a required level of QoS.
It is a general objective of the present invention to overcome or significantly mitigate one or more of the aforementioned problems.